The present invention relates to software, and more specifically, to making incompatible software applications compatible with an operating system.
In today""s rapidly moving software field many applications are programmed specifically for the operating system in use at the time the application is developed. While programming specifications are typically provided to application developers by the operating system developers, sometimes these procedures and rules are not followed. As a result, many applications may not work correctly under a new release of an operating system. This can result from many different factors, including not following the programming specifications or making assumptions about how the operating system operates. For example, an application developer may believe that a certain type of file is always stored at a specific location in the computer, and instead of requesting the location of the file from a function in the operating system, as the programming specifications indicate, the programmer will specifically input the path of the file location into the application code. Additionally, a programmer may rely on the fact that a certain function of the operating system only returns a certain value if an error occurs within that function. For example, if previous versions of the operating system returned a value of negative one to indicate an error, the programmer may assume that only a negative one value will be returned in the future. An operating system change, however, may have modified the function to return other values based on the error, thereby potentially causing the program to not work correctly in all situations under the operating system.
In other instances, a program may seem to operate correctly under one version of an operating system even though it contains errors. This can occur when the older version of the operating system does not detect or enforce the error contained within the application. A new release of the operating system, however, may check for these previously unchecked conditions, thereby causing the application to be incompatible with the new version of the operating system.
Further creating incompatible applications is the fact that as the popularity of the operating system increases, the problem of incompatible applications also increases. For example, if an operating system has become popular during its release, there will be thousands of applications written specifically for that operating system. The large number of applications, as well as the diverse group of application developers, can result in many programs not working correctly when a new version of an operating system is released.
Users of currently working applications may not want to switch to a newer operating system if their applications are incompatible with the new operating system. To attempt to solve this problem, application developers have been required to fix their applications themselves, or operating system developers have included patches that are integrated into the new version of the operating system to fix many of the known problem applications so that they may function correctly under the new operating system.
The operating system patch approach, however, creates many problems. First, patches may add a significant amount of data to the operating system that may significantly increase the space requirements of the operating system. Second, all applications are required to operate through this additional patch layer even though many applications are compatible with the new operating system. This can cause programs to run slower. Third, the operating system programming code may become very cluttered due to the number of programs that may need to be fixed. This cluttered code makes it more difficult for operating system developers to make changes and improvements to the operating system. Finally, it is impossible for a developer to know all of the applications that will not work correctly when the new operating system is first released. Therefore, subsequent patches must be made to the operating system in order to allow these programs to work correctly. This in turn adds another layer to the already complex operating system causing the operating system to operate in a less efficient manner.
The present invention is directed to providing a system and method for patching an application that would not otherwise be compatible with the operating system of the computer on which the application is run. In accordance with the invention, a dynamic link library (DLL) is inserted into the incompatible application""s address space. The DLL determines the functions in the incompatible application that need to be patched and patches those functions.
It will be appreciated that the DLL is only loaded by the operating system for those applications that have been identified as being incompatible with the operating system. Therefore, applications that are compatible with the operating system are not required to go through an additional operating system level while executing, thereby preserving system resources.
One embodiment of the invention works in the following way. First, the user starts an application. Second, the application is identified as being compatible or incompatible with the operating system. To determine if the application is incompatible, identifying information from the application is checked against a database containing a list of applications that are currently known to be incompatible. If the name of the application is in the database then a set of attributes are checked to see if that particular version of the application is compatible. If all of the checked attributes match the ones found in the database, the application is determined to be incompatible with the current operating system.
If the name of the application is not found in the database, the application is determined to be compatible with the current operating system. If the application is determined to be compatible, the application runs normally. If the application is determined to be incompatible, the operating system loads a DLL into the application""s address space that acts as a shim between the application and the operating system. The Shim DLL contains the program code necessary to apply the patches that are contained in a separate DLL, which is referred to as a Hook DLL. The Hook DLL contains the actual program code required to patch the incompatible application.
After loading the Hook DLL, the Shim DLL analyzes the contents of the Hook DLL to determine what functions need to be patched in the application. In one embodiment of the present invention, the Hook DLL may also contain: the name of the module where the incompatible function is located; the function name that is incompatible; the stub functions that should be called in order to fix the problem; and the list of the application""s DLLs that need to be patched. The information contained in the Hook DLL is then used by the Shim DLL to patch the incompatible application""s program code.
After the Shim DLL and Hook DLL are loaded by the incompatible application the remaining DLLs required for the application are loaded. Each of the loaded DLLs has an import table that maintains a list of the functions and function pointers that are contained within the DLL. The Shim DLL replaces the incompatible function pointer(s) in the DLL with the updated function pointer contained within the Hook DLL.
In accordance with other aspects of this invention, in addition to patching DLLs as they are loaded at runtime, a method and system for patching a DLL that is dynamically loaded during the execution of an application are provided. In order to correct incompatibilities within the dynamically loaded DLL the operating system patches by default a few system APIs that an application would use to dynamically link to a DLL and call APIs from that DLL.
As will be appreciated by those of ordinary skill in the art from the foregoing summary, the present invention provides an efficient method of patching incompatible applications.